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(54) Process for compressing digital certificates for use in smart card 



(57) A technique for compressing certificate infor- 
mation for use in portable credit instruments having lim- 
ited storage capacity. An end user certificate typically 
actually, comprises a chain of certificates, as SET trans- 
actlon&requlre not only the end user certificate and its 
parent certificates. Each certificate in the certificate 
chain is compared to a template for that certfficate. and 
the differences are stored. Redundant differences within 
each certificate are deleted, as are differences which 
may be derived from differences stored for other certif- 
icates in the certificate chain. The remaining stored dif- 
ferences are then recorded on an end user credit instru- 
ment, such as a smart card. Preferably, the certificate 
chain is then recreated for verification purposes before 
the card is issued. PER encoding may also be employed 
to further compress the certificate information to be re- 
corded on the crec» instniment 
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Description 

[0001 ] The present invention relates to a technique for 
cxxnpressing digital certificates. More particularly; the 
present Invention relates toa technique for connpressing 
digital certificates used in secure electronic transactions 
(SET) so that their memory requirements are minimized 
to permit nrK>re data, such as multiple certificates, to be 
stored on credit instruments having memory limitations, 
such as smart cards. 

[0002] A major drawt>ack to the acceptance of elec- 
tronic commerce has been public coricerr^ over secu- 
rity on the Internet. High^ publicized instances of elec- 
tronic eavesdropping, hackers breaking into military 
computers, etc., have reduced the publte's trust in the 
Internet as a safe way to conduct business. Unless the 
public is convinced that it is safe to use their credit cards, 
debit cards or checks (in electronic form) to make tTEHis- 
actions over the Internet, the Intemet will not beooma a 
viable commerced vehicle. 

[0003] To this end, a number of companies have been 
developing a highly secure set prc^ocols to ^un the 
public's trust for electronic commerce. One of these pro- 
tocols, known as SET (secure electrons transactions), 
combines encryption technology and digital signatures, 
provides for instant verifkatksn for merchants, and min- 
imizes the amount of personal inforrretlon (in the form 
of credit card numt)erB, etc.), that is exposed to parties 
involved in a SET transaction, including merchants. 
PKMM] SET relies on the use <tf digital certifk:ates to 
authentk»te the digital signature of the holder of an 
electronic/digital credit instrument with regard to a pay- 
ment instruction. For the purpose of electronic com- 
merce, a bank issues to its customers electronk:/digital 
versions of credit instmments such as credit cards, debit 
cards, checks, etc. Data in the electronic credit instru- 
ment (known as a certifk»te), such as a credit card 
number, e^qpiration (^e, etc., is encrypted or otherv^'se 
masked. The certificate also includes the cu^omer^/ 
consumer's digital signature key. When a consumer 
makes a purchase from a merchant over the Intemet 
using a certificate whnh represents a credit card, the 
certificate is transmitted to the merchant, which trans- 
mits the certificate to the approprate bank based on 
ta contained in the certifkste. The merchant never sees 
the data contained in the digital signature, and only has 
access to limited information contained in the certificate. 
However, the merchant can be relatively secure in the 
belief that the buyer is very likely the actual account 
holder for the credit instrument (brand) utilized to make 
the purchase, and that the buyer did in fact °sign° the 
payment instruction. Public key encryptbn permits the 
information to be communicated with minimal fear that 
electronic eavesdroppers can decrypt the data con- 
tained In the data transfer over the Intemet. The t>ank 
approves the transactk)n by verifying the digital signa- 
ture, detemnlning that the account is active and in good 
standing, that suffk:ient funds are in the consumer^ ac- 



count/the consumer has not gone over his credit limit, 
etc.. and sending the merchant an indicatbn of the ap- 
proval. The merchant Is credited by the bank in the 
amount of the transactbn, and the bank debits the con- 

5 sumer^ account. 

[0005] In the United States in 1 997, most consumers 
are involved in a form of electronic commerce every cfeiy 
through the use of their credit cards, debit cards, check 
cards and ATM cards. These cards utilize a magnetic 

10 strip to store consumer account data. However, this 
magnetic strip can contain only a minimal anrK>unt of da- 
ta (on the order of 1 00 bytes) which can easily be copied 
onto a fraudulent card. While 100 bytes is enough to 
store t>astc account informatton such as an account 

IS number, an account name, an expiratton cfeite. etc.. for . 
one or two accounts, magnetic strip cards do nc^ provide 
sufficient storage to store nnformatron for multiple ac- 
counts, much less an encrypted digital certificate. While 
magnetic strip cards are relative^ inexpensive, costing 

20 less tfian a dol^ each, they have no ability to perform 
processing or interact with the merchant or card holder 
in any other way, or provkfe storage for any c^er pur- 
pose. 

[OOOS] In other parts of the world, especially Europe, 

2S smart cards have ^ined wkie acceptance. Smart cards 
have several times the storage capacity of common 
American magnetk: strip cards, and often have logic 
built in which makes the smart cards extremely diffk:ult 
to compromise without detection by the card hokter 

30 Smart cards are protected by PlNs (personal kientiftea- 
tion numbers), so account informatkm cannot be di- 
vulged without the cooperation of the cardhokter. fttore 
sophisticated smart cards contain, a secret syrrvnetric 
key which can be used to sign a payment instructk>n up- 

3S on PIN entry. Only the bank krK>ws the actual secret key 
on the smart card, can it can verity that the cardhokter 
agreed to a given payment instructkm. The strength of 
this scheme is that the account number is never di- 
vulged to a merchant, and thus, cannot be rep^ed for 

40 fraudulent purposes. However, smart cards are several 
times the cost of a common American credit card, sev- 
eral dollars versus less tfian a do!^. 
[0007] The most sophisticated smart cards, called 
"multrfunctton cards, ° can be programmed for many on- 

45 tx)ard applications, including public key signatures. One 
of the requirements of SET is that when a cardhoktor 
sut)m*its a payment instmctkin to a merchant, the caid- 
hokler implementatbn must provkie its own certifk^te. 
In additkxi to its own certifk:ate, the cardhokler imple- 

50 mentatbn must provkie the certificate of the certificate 
authority which signed the cardholder certificate, called 
the certifk:ate Issuer. Furthermore, every Issuer up to 
and including the SET Root Certificate must be includ- 
ed. Collectively, these certificates are referred to as the 

ss certificate chain. These smart cards are several times 
the cost of a common smart card, currently about 
$10-$25 dollars versus several dollars, and still lack 
enough storage to hokJ more than one consumer certif- 
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icate and all of the certificates In the hierarchical certif- 
icate chain. 

[00OS| Given the growing popularity of SET, the limit- 
ed storage space available on magnetic strip cards, and 
the proven effectiveness of smart cards, it makes sense 
to use SET in combination with smart cards. But given 
the cost smart cards, an effective way is needed to store 
more than one credit Instrument/SET certificate on a sin- 
gle smart card. Accordingly, a need has developed for 
a technique for storing multiple certificates on a single 
smart card or any credit instnjment for which storage Is 
limited. 

[0009] An object of the present invention Is to provide 
a technique for storing more than one certificate on a 
conventlonai srrart card. 

[0010] Another object of the present Invention Is to 
provide a technique for storing multiple certificate-based 
credit instruments In a single smart card. 
[001 1] Yet another object of the Invention is to provide 
a technique for providing enhanced security for srrart 
card transactions. 

[0012] Still another object of the present invention is 
to enable the same type of secure transactions for both 
lntemet-t>ased transactions and card-based transac- 
tions. 

[0013] Other objects and advantages of the present 
Invention will be set forth in part in the description and 
the drawings which follow, and. In part, will be obvious 
from the description or may be teamed by practice of 
the Invention. 

[001^ To achieve the foregoing objects, and in ac- 
cordance with the purpose of the invention as broadly 
described herein, the present invention provides a soft- 
ware implemented process for use In a computhg envi- 
ronment for compressing certificate data from a certifi- 
cate chain, comprishg first subprocesses for selecting 
a first certificate in the certificate chain for processing; 
second subprocesses for determining a certificate tem- 
plate which corresponds to the selected certificate; third 
subprocesses for determining and storing the differenc- 
es between the selected certificate and the tempterte; 
fourth subprocesses for repeating the first, second and 
third subprocesses for the remaining certificates m the 
certificate chain; and fifth subprocesses for storing the 
differences In an end user credit instmment. Preferably, 
the end user credit Instrument is a smart card. Further, 
the process may further comprise sixth subprocesses, 
carried out after the third subprocesses, for deleting dff- 
ferences which can be derived from other stored dfffer- 
ences. Additionally, the prcx^ess may further comprise 
seventh subprocesses for recreating the certificate 
chain and comparing the recreated certfficate chain to 
the original certificate chain, and if any differences are 
found, indicating an error. The process may further com- 
prise eighth subprocesses, carried out for each certifi- 
cate after the third subprocesses, for determining 
whether any of the differences for the certificate being 
processed can be derived from other stored differences. 



and if so, deleting the differences; and ninth subproc- 
esses, carried out for each certificate after said eighth 
subprocesses, for deleting differences which can be de- 
rived from dffferencGS already stored for other certifi- 

s cates in the certfficate chain. 

[0015] The present invention also provides a system 
for compressing certificate data for reducing storage re- 
quirements for a certfficate chain, comprising means for 
determining differences between each certificate in the 

10 certificate chain and a corresponding certificate tem- 
plate; means for storing the differences; means, retative 
to each certificate, for determining which differences 
may be derived from other differences stored for each 
certificate and deleting the differences determined to be 

IS derivable; and means for storing the remaining differ- 
ences on a credit instrument The system further com- 
prises means for employing PER encoding when storing 
the remaining differences on the credit instrument 
Additionally, the present invention provides a method for 

20 compressing a cfigital certificate comprising a certificate 
chain and storing the compressed certificate chain on a 
credit instrument, comprising the steps of determining 
differences between each Individuat certifk:ate in the 
certificate cfiain and a base certfficate for each of the 

2S individual certificates; storing the dffferences; for each 
of the individual certfficates, detemnining which dfffer- 
ences are redundant and deleting the redunctent differ- 
ences; and recording remaining differences on a cr^ff 
instrument Themethod may further connprise the step 

30 of, after said determining step, deleting other differenc- 
es which may bB derived from dffferences stored for o2h* 
er certfficates. 

[001S| Additionally, the present Invention provides an 
end user credit Instrument having a compressed certif- 
35 tcate chain stored therein. 

[0017] The present invention will now be described 
wHh referBrK:e to the follofwing drawings, in which like 
reference numbers denote the same element through- 
out. 

40 

Figure 1 is a block diagram of a computer-based 
smart card encoding system in which the present 
inventkn may be practiced; 

45 Figure 2 Illustrates examples of SET certffk»te tem- 
ptertes; 

Figure 3 illustrates a SET certfficate hierarchy; 

50 Figures 4A-4B illustrate a flow chart which sets forth 
the logic involved with the present invention; and 

Figure 5 Illustrates data which Is related between 
different certfficates In a certificate hierarchy. 

55 

[0018] Figure 1 illustrates a representative worksta- 
tion hardware environment in which the present inven- 
tion may be practiced. The environment of Fig. 1 com- 
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prises a representative single user computer worksta- 
tion 10, such as a personal computer. Including related 
peripheral devices. The workstatk^ 10 Includes a mi- 
croprccessor 1 2 and a bus 1 4 employed to connect and 
enable communication between the microprocessor 12 s 
and the components of the workstation 10 in accord- 
ance with known techniques. The workstatbn 10 typi- 
cally includes a user interface adapter 16, which con- 
nects the mk;roprocessor 12 via the bus 14 to one or 
more interface devk:es, such as a keyboard 18, mouse io 
20. The workstation 10 may also have a smart card 
reader/writer 22 associated therewith, which is able to 
. encode smart cards and read information from snr»rt 
cards. Other interface devices, such as interface device 
23, which can be any user Interface devtoe, such as a is 
touch sensitive screen, a digitized entry pad, ^c, may 
also be associated with the workstation 10. The bus 14 
also connects a display devk;e 24, such as an LCD 
screen or monitor, to the microprocessor 12viaadisplay 
adaptor 26. The bus 1 4 also connects the microproces- ^ 
sor 12 to memory 28 and bng temrt storage 30 whk4i 
can include a hard drive, tape drive, etc. 
[001S] The workstation 10 communicates via a com- 
munications channel 32 with other computers or net- 
works of computers. The workstatk>n 10 may be asso- ^ 
dated with such other computers in a kscal area network 
(LAN) or a wkle area network, or the workstatkm 10 can 
be a client in a client/server arrangement with another 
computer (such as a mainframe computer), etc. All of 
theseconfiguratnns, as wellastheappropriatecommu- so 
nk^ations hardware and software, are known in the art. 
Using the communlcatbns channel 32, certifk»te infor- 
rnaXksn may be provkied to the woritstation 10 from a 
mainframe computer or central database which proc- 
esses or distributes certificate informatk)n that is to be ^ 
encoded on smart cards. Other known computer system 
configurations may also be employed to implement the 
subject inventbn. 

[002Cq The specifk; technobgy employed for writing 
to or reading data from smart cards is well known, and 40 
will not be further discussed herein. 
[0021] Software programming code which embodies 
the compression technique according to present inven- 
tion is typically accessed by the microprocessor 12 of 
the workstatkm 10 from long term storage media of ^ 
some type, such as a CD-ROM drive or hard drive, 
whk:h is represented by the k>ng tenm storage 30 of the 
workstatbn 10. In a client/sen/er environment, such 
software programming code may be stored with storage 
associated with a sender. The software programming so 
code may be embodied on any of a variety known 
media for use with a data processing system, such as 
a diskette, or hard drive, or CD-ROM. The code may be 
distributed on such media, or may be distributed to users 
from the memory or storage of one computer system ss 
over a networit of some type to other computer systems 
for use by users of such other systems. The technk^ues 
and methods for embodying software program code on 



physbal media and/or distributing software code via net- 
works are well known and will not be further discussed 
herem. 

[0022] One aspect of secure electronk: transaction 
(SET) protocol is the reliance on the exchange d certif- 
icates during a transaction. SET certificates are based 
on the X509 standard. Figure 2 illustrates the types of 
data included in a standard SET certificate 40 issued to 
an end entity, such as a credit cardhokier, a merchant, 
or a payment gateway. The certificate 40 includes re- 
quired or standard X509 certificate 42, such as 
version informatk^n. a serial number, the name of the 
issuer of the certificate (the issuing bank in the case of 
a credit card), the per»d during whteh the certificate is 
valkl, the issuer ID, a subject ID, eto. The certificate 40 
also includes a numt>er of defined X509 extenskins 44, 
such as certificate polk:y infonr^tton, key usage infor- 
matbn. key identifier informatbn, alternate names, etc. 
The certificate 40 also includes a number of SET-spe- 
cific (private) extenstons 46. such as certificate type in- 
formation and merchant c^ta. Rgure 2 also illustrates a 
certificate authority 48 which issued the certificate 40, 
and the arrows point out relatk^nships between the data 
recorded on the certificates 40, 48, whteh are exploded 
by the present inventbn to compress data, as discussed 
betow. 

[0023] During a transactksn, SET certificates are ver- 
ified through a hierarchy of trust Each certificate is 
linked to the certificate whk:h issued or digitally signed 
It. By going up the hierarchy to a known trusted party, a 
party can be assured that a certificate is valkJ, for exam- 
ple, a merchant can be assured that a credit card certif- 
icate provkJed by a customer is valkJ. A SET transaction 
thus requires an entire certificate chain, and while an 
end entity certificate is the only one that contains con- 
sumer specific inf ormatkm, ttie consumer needs to have 
not only her unique end entity certificate, but all of the 
parent certificates fonm the hierarchy. All of these certif- 
bates are provided to the merchant in order to carry out 
atransactbn. 

[002^ As illustrated in Figure 3, end entity certificates 
50, 52, 54. 56, 58. such the certificate 40 of Figure 
2, are part of an overall certificate hierarcfiy 60. End en- 
tity certificates are at the end of the hierarchical chain, 
and they do not issue certificates (and thus are not "cer- 
tificate authorities"). Fattier, they are issued by the cer- 
tlfk^ate immediately above them m the hierarchy. Certif- 
bates which have the ability to issue certificates are also 
known as certificate authorities. At the top the hierar- 
chy is a root certificate 62, which is the originating or 
parent certificate for all of the certificates in the hierarchy 
60. Next in the hierarchy is a brand certificate 64, whk:h 
is issued by the root certificate 62. In the case of credit 
cards, the brand certificate 64 can be, for example, VISA 
or MasterCard. These certificates betong to the compa- 
nies tiiat own these brands. The brand certificate 64 
may issue a geopolitical certificate 66, which is optional. 
A geopolitkal certificate many be required in certain 
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countries, and include national rules/country specific in- 
tonnation. The brand certificate 64 (or the optional ge- 
opolitical certificate 66) is used by the credit card issuer 
to issue certificates 68. 70, 72 to their agents, such as 
banks, which issue end user certificates to consumers s 
and merchants. The credit card certificate 68 is used to 
issue credit card certificates for use by consumers, the 
merchant certificate 70 to issue certificates to be used 
by merchants to process credit, card certificates re- 
ceived fiom consumers during transactions, and the io 
payment certificate 72 is used to issue certificates to be 
used in conjunction with payment gateways, which proc- 
ess transactions. 

[0025] As discussed, the certificate 68 issues credit 
card certificates, such as the end entity certificate 50. A is 
consumer to whom the certificate 50 is issued is actually 
required to have the entire certificate chain in order to 
carry out a transaction with a merchant, in accordance 
with the SET protocol for certificate auttientication. 
Thus, a consumer's smart card must have all four or five 20 
cert'tficates in the chain (certificates 50. 68, 66. 64, 62) 
included on her smart card, depending on whether or 
not the geopolitical certificate is required. 
[002G| As illustrated in Figure 2. much of the data con- 
tained in different certificates is the hierarchy is redun- 
dant from one certificate to another certificate in the hi- 
erarchy. Also, each certificate has certain data which is 
stancterd. For example, the certificate 68 will typically 
include data whteh identifiesthebankand provides bank 
Information for routing the transaction to the bank. The ^ 
brand certificate 64 rncludes brand information whnh 
kientifies the type of credit card. These are examples of 
information whnh is repeated in each tower certifk»te 
in the chain. 

PSOZTI TTiek^k: Involved with connpressing and stDT- ss 
Ing a certifnate chain on a smart card will now be de- 
scribed with reference to the flow chart of Rgure 4. 
[0028] As per Step 100. a determinatk>n is first n^de 
as to which certifk»te in the certificate chain to be toad- 
ed hto the memory of the snart card is the highest level 40 
or root certifkaite (the certifk^te with no higher level or 
parent certificate that needs to be foaded). Ordinarily, 
this certificate will be the root certificate 62 the hier- 
archy chain, which is a subset of tiie hierarchy 60. In 
this example, the root certificate 62 is selected for ^ 
processing. 

[0029] After a determinatbn is rnade in Step 100 as 
to which certificate is the highest certificate in the hier- 
archy to be loaded onto the smart card and that certifi- 
cate is selected, the certificate type for the selected cer- so 
tificate is determined in Step 102. The SET protocol de- 
fines each certificate in the SET hierarchy Thus, a 
"blank** or template exists for each certificate in the hi- 
erarchy. As discussed, each certificate includes certifi- 
cate type ffiformatton in its private extensions. By read- ss 
ing tills information, the certificate type may be d^er- 
mined, and tiie certificate matched to its template. Ac- 
cordingly, ttte certificate type for the selected cert'rficate 



is determined and the template for the certificate type is 
selected for use in further processing according to the 
present invention is Step 102. 
[0030] As discussed above and illustrated in Figure 2, 
each SET certificate type has a template to whtoh data 
is added by the issuer. Thus, much of the data contained 
in an issued certificate is redundant to its temp^te. In 
Step 104. the differences between the tenplate for the 
selected cert^k:ate and the selected certificate itself are 
determffied and recorded in a storage devtoe assoc^ed 
with a system for storing data on indrvkf ual smart cards. 
[00311] As discussed, a certificate chain must be rec- 
reated in its entirety when an end user, such as a con- 
sumer, uses her credit card certificate 50. By providing 
the templates for all the certificates in a hierarchy at the 
point of use, it is a relatively simple matter to reconstruct 
each certificate in a certificate hierarchy by reading the 
compressed certificate data off of a smart card and plac- 
ing it into the appropriate focatfon with the templates. 
However, it is rust even necessary to store all of the dif- 
ferences between a certificate and its temple in order 
to reconstruct the certificate. Thus, further compressbn 
can be obtained through tiie use of a few addrtksnal com- 
pressbn steps and an appropriate programmed recon- 
struction algorithm whteh is conriplennentBry to the com- 
pressbn process. Some of the certificate^specific data 
included on some SET certificates is redunctent based 
on how the SET certificate is defined, and thus some off 
the differences will t>e redunctot if stored on a smaat 
card. Accordingly, some of the values representing the 
differences between a certificate and its template may 
fc>e derived from other values from among the recorded 
differences. Thus, as per Step 108, some of tiie record- 
ed values are deleted. Selecting whk:h redundant val- 
ues are to be deleted may be performed in any of a 
number of ways. However, tiie selected manner must 
be reflected in the certificate reconstruction algorithm 
whbh reconstructs tiie certificate hierarchy when a con- 
sumer attempts to use the snr»rt card. As discussed, tiie 
entire certificate hierarchy including each certificate in 
the hierarchy in its entirely is required when a certificate 
is utilized by a consumer. Accordingly, while it is a rela- 
tively simple matter to reconstruct a certificate by pac- 
ing information stored on a smart card into predefined 
blanks In a common template for each certificate in a 
hierarchy, it is more complk:ated when some of the En- 
formation is required to be utilized more tfian once when 
reconstructing a certificate. The reconstructbn algo- 
rithm must know if certain data from a smart card is to 
be used in more tfian one kdcatfon in a certificate being 
reconstructed. 

[0032] Another technk)ue for furttier compreissing the 
data that will be stored in the smart card will now be 
discussed relatVe to Steps 108 and 110. In the case of 
the root or highest certificate 62 in the hierarchy chain 
undergoing compressk>n, tfiere is no higher certificate 
being compressed. Step 108 determries wh^er the 
certificate being processed is the highest level certifi- 
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cate/whether the certificate being processed was issued 
by a certificate that has already been processed. If not, 
processing proceeds to Step 1 1 2. However, if the certif- 
icate being processed was issued by a previously proc- 
essed/compressed certificate, processing proceeds to s 
Step 110. In addition to there being redundant informa- 
tion within a given certificate, the SET definitions dictate 
that there is often redundant infonmatbn found in differ- 
ent certificates within the hierarchy chain. Similarly to 
the process described above relative to Step 1 0S, this f o 
redundant Information need only be stored once in the 
smart card (as long as the data in the smart card can be 
appropriately reconstructed to recreate the entire hier- 
archy). Thus. , certain ffiformation may be deleted rela- 
tive to the certificate being processed. Rgure 5 illus- 
trates this an example of this redundancy. Elements 
62A, 64A, 68A illustrate a subset of the data found in 
certificates 62. 64, respectively. The arrows indicate 
where common data is found tn different areas of the 
certSicates. For example, the "Name" information from ^ 
the root certificate 62 is also the Issuer" and "AuthK^- 
\D° information in the root certificate 62. the Issuer" and 
"AuthKeylD" information in the brand certificate 64 and 
the "AuthKeylD" information in the cardholder issuing 
certificate BB, Thus, in Step 108. information from the ^ 
recorded differences which has already been recorded 
relative tea previously processed certificate is identified 
and deleted. Once again, the reconstruction algorithm 
is appropriately programmed to find this information in 
the smart card and place it in all of the necessary Eoca- ^ 
tions in the various certificates it recreates upon use of 
the smart card. 

[0033] If the certificate was found to be the highest 
issuing certificate in Step 1 08 or after the processing of 
Step 110, processing proceeds toStep 112. InStep 112, 3S 
it is determined if any certificates rennain to be proc- 
essed. In the case of the root certificate 62, the brand 
certificate 64, the geopolitical certificate 66 and the 
cardholder issuing certificate 68, the determirmtion will 
be that not all of the certificates have been processed. ^ 
Processing will then proceed to Step 114. and the next 
lower certificate in the chain will be identified and select- 
ed, and processing will return to Step 1 02 for processing 
of the newly selected certificate. For the root certificate 
62, the certificate 64 will be selected in Step 114 for ^ 
processing. When the end-user certificate 50 is finally 
selected and processed. Step 112 will determ^e that no 
lower certificates remain to be processed, and process- 
ing will proceed to Step 116. 

[0034] The data which is recorded should now be a SO 
subset of the differences between the various certificate 
templates and the issued certificates in the certificate 
hierarchy chain. The data is recorded so that a recon- 
struction algorithm can reconstmct all the certificates in 
the hierarchy chain. Preferably, the data is recorded with ss 
the differences from the highest certificate in the chain 
recorded first, and data from each subsequent lower 
certificate recorded sequentially. Not all of the differenc- 



es will be present, as some ofthedata will be redunc^. 
Thus, the reconstruction algorithm, which is pro- 
grammed with or has access to the templates, is able to 
read the differences sut>set and reconstruct each certif- 
icate in the hierarchy. Typically, the reconstmctton algo- 
rithm win be stored at the location/in the equipment at 
which the end user uses her certificate, such as an ATM 
machine, a merchanf s smart card reader equipment, 
etc. Accordingly, as per Step 116, the recorded data is 
stored on the end user^ snrart card (Bfi accordance with 
known smart card data recording/encoding techniques). 
Next, in accordance with the prefened embodiment, the 
smart card is tested for quality control purposes. In Step 
1 1 8, an attempt is made to recreate the certificate chain 
from the data stored on the smart card using the rsoon- 
stmctton algorithm. Thus each certificate in the recroat- 
ed certificate hierarchy is then compared to the original 
to determine If the compression attempt has been suc- 
cessful. If it is determined in Step 120 that the original 
certificates match the recreated certificates, then 
processing ends, and the compression arxl creation of 
tiie smart card is deemed to have been successful. The 
smart card is then ready for distribution to an end user. 
However, if it is determined in Step 120 that In any 
of the recreated certificates does nc^ rr^tch that en the 
originals, processing proceeds to Step 1 22, in which the 
compressed certificate data that was stored on the 
smart card is erased. Processing then returns to Step 
1 00, and a new attempt Is made to compress and store 
the certificate data on the smart card. Continued failures 
to get a match In Step 120 could Indicate a defective 
smart card, or a software error in the software for the 
reconstruction algorithm or the compression software, 
or an error in the original certificate data itself. 
[0035] An optional additional step nrmy be employed 
before Step 116. The optional step further compresses 
the certificate information by employmg PER encoding, 
which provides a very compacted encoding. PER en- 
coding cannot be used for the actual certificates, but can 
be employed as an intermediate storage, as long as the 
encoded pieces are re-encoded into DER. 
[003S) While the present mention has been de- 
scribed relative to smart cards, the basic techniques de- 
scribed herein may be applicable to many types of port- 
able credit instruments which require or utilize digital 
certificates. Thus, while the preferred embodiment of 
the present invention has been described, additional 
variations and nriodrfications In ttiat embodiment iray 
occur to those skilled in the art once they learn of the 
basic inventive concepts. 



Clalmo 

1. A computer readable code for compressing certifi- 
cate data from a certificate chain in a computing en- 
vironment, characterised by first subprocesses 
(1 00) for selecting a first certificate In tiie certificate 
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chain for processing; second subprocesses (102) 
for determining a certificate template which corre- 
sponds to the selected certificate; third subprocess- 
es (104) for detemnlning and storing the differences 
between the selected certificate and the template; s 
fourth subprocesses (112.114) for repeating said 
first, secoTKl and third subprocesses for the remain- 
ing certificates in the certificate chain; and fifth sub- 
processes (116) for storing the differences in an end 
user credit Instrument io 

2. A computer readable code for compressing certifi- 
cate data according to Claim 1 , further character- 
ised by sixth subprocesses (122), carried out after 
said third subprocesses, for deleting differences is 
which can be derived from other stored differences. 

3u A computer readable code for compressing certifi- 
cate data according to Claim 2, further character- 
ised by seventh subprocesses (118) for recreating 20 
the certificate chain and comparing the recreated 
certificate chain to the original certificate chain, and 
if any differences are found, indicating an emor. 

4. A computer readable code for compressing certifi- 
cate data according to Claim 1, further character- 
ised by eighth subprocesses (120), earned out for 
each certificate after said third subprocesses, for 
determining whether any of the stored differences 
can be derived from other stored differences, arKJ if 30 
so, deleting the stored differences (122); and ninth 
subprocesses, carried out for each certificate after 
said eighth subprocesses, for deleting cfifferences 
which can be derived from other certificate differ- 
ences already stored for other certificates in the cer- 3S 
tificate chain. 

5. A computer readable code for compresshg certifi- 
cate data according to any one of Claims 1 to 4, 
diaracterised in that the end user credit instrument 40 
is a ^nart card. 

6. An end user credit instrument having compressed 
certificate data chain stored therein by effecting the 
steps of first subprocesses (100) for selecting a first ^ 
certificate in the certificate chain for processvig; 
second subprocesses (102) for determining a cer- 
tificate template which corresponds to the selected 
certificate; third subprocesses (1 04) for determining 
and stonng the differences tsetween the selected so 
certificate and the template; fourth subprocesses 
(112,114) for repeating said first, second and third 
subprocesses for the remaining certificates in the 
certificate chain; and fifth subprocesses (116) for 
storing the differences in the end user credit instru- ss 
ment 

7. A system for compressing certificate data for reduc- 



ing storage requiremente for a certificate chain, 
characterised by means (100, 102) for determining 
differences between each certificate in the certifi- 
cate chain and a conesponding certificate template; 
means (104) for storing the differences; means 
(1 1 2, 1 1 4), relative to each certificate, for determin- 
ing which differences may be derived from other dif- 
ferences stored for each certificate and deleting the 
differences; means (116) for storing the remaining 
differences on a credit Instrument 

a A system for accessing data according to Claim 7, 
further characterised by means for employing PER 
encoding when storing the remaining differences on 
the credit Instrument 

9. A method for compressing a digital certificate and 
storing the compressed chain on a credit instm- 
ment, characterised by the steps of: detenmtning dif- 
ferences between each individual certificate which 
comprises the digital certificate and a template for 
each of the Individual certificates; storing the dSTer- 
ences; for each of the individual certificates, d^er- 
mining which differences are redundant and delet- 
ing the redundant differences; and recording re- 
maining differences on a credit Instrnment 

10. A method aooorcfing to Claim 9, further character- 
ised by the step of: after said determining step, de- 
leting other differences which may be derived from 
differences stored for other certificates. 



8 



EP0927g74A2 



PROCESSOR 




MOUSE 



22 
J— 



INTERFACE 
DEVICE 



16 



USER 
IffTERFACE 
ADAPTER 



23 
/ 



INTERFACE 
DEVICE 



14 

jC— 



26 



DISPLAY 
ADAPTER 



STORAGE 



,30 



28 



MEMORY 



ii 



DISPLAY 
DEVICE 



32 



HG.1 



9 



EP0927g74A2 



END Ei^rmr certificate 



CACERTIRCATE 



4<K 



CERTIFICATE: 

VERSION 
SERIALNUMBER 
ALGORrTHMiDENTIFER 
ISSUER NAME 
VAUDITY 

NOTBEFORE 
NOTAFTER 
SUBJECT NAME 
SUBJECT PUBLIC KEY INFO 
ISSUERUNIQUBD 
SUBJECT UNIQUE ID 




EXTENSIONS: 

/AUTHORITY KEY IDl 

keyidentifer/ / 
certissuer/ / 
cbttserialnumber 
keyusage 
— h(eyusage 

/ PRiVATEKEYUSAGEPEfillOD 
/ VAUDITY 
^ NOTBEFORE 
NOTAFTER 
CERTinCATEPOUCIES 

POUCYOID 

QUAURER 
SUBJECTALTNAME 

GENERALNAMES 
GENERALNAME 
BASIC CONSTRAINTS 
SUBJECTTYPE ' 
PATHLENCONSTRAINT 
ISSUERALTNAME 

GENERALNAMES 
GENERALNAME 



\ 



PRIVATE EXTENSIONS: 
T^^^-CERTIRCATE TYPE 
4^ MERCHANT DATA 



X^CERTIRCATE: 
VERSION 
SERIALNUMBER 
ALGORITHMIDBmFER 
ISSUER NAME 
VAUDfTY 

NOTBEFORE 
NOTAFTER 
SUBJECT NAME 
SUBJECT PUBUC KEY INFO 
ISSUERUNIQUEIO 
SUBJECT UNIQUE ID 

X^ EXTENSIONS: 

AUTHORrrY KEY IDENTIFER 
KEYIDENTIFER 
CERTISSUER 
CERTTSERIALNUMBER 
KEYUSAGE 
KEYUSAGE 

PRIVATEKEYUSAGEPERIOD 
VAUDITY 

NOTBEFORE 
NOTAFTER 
CERRRCATE POUCIE8 
POUCYOID 
QUAURER 
SUBJECTALTNAME 

GENERALNAMES 
GENERALNAME 
BASIC CONSTRAINTS 
SUBJECTTYPE 
PATHLENCONSTRAINT 
ISSUERALTNAME 

GENERAL NAMES 
GENERALNAME 



PRIVATE EXTENSK)NS: 
— »fcERTIRCATE TYPE 

CARDHOLDERCERTIRCATERQD 
TUNNEUNG 



Fia2 



10 



EP0927 974A2 



62- 



ROOT 
SIGNATURE 



64- 



BRAND 
SIGNATURE 



60 




GCA 
SIGNATURE 



MCA 

SIGNATURE 



CAROHOLOEF 
SIGNATURE 



50 



MERCHANT 
SIGNATURE 



"7" 
S2 





MERCHANT 

KEY 
EXCHANGE 
T ^ 



PAYMENT 
GATEWAY 
SIGNATURE 



54 



56 



PAYMENT 
GATEWAY 
KEYEXCHANGd 
T 



58 



HG.3 



11 



EP0927g74A2 



^ START ^ 



DETERMINE AND SELECT 
HIGHEST CEFniRCATE IN 
CHAIN 



.100 



DETERMINE CERTIFICATE 
TYPE OF SELECTED 
CERTinCATE; SELECT 
CORRESPONDiNG 
TEMPLATE 



I 



.102 



DETERMINE AND STORE 
DIFFERB4CES BETWEB4 
SELECTED CERTIFICATE 
AND TEMPLATE 



.104 



I 



BASED ON DERNED 
RELATIONSHIPS. OMIT 
VALUES WHICH CAN BE 
OBTAINED OR DERIVED 
BASED ON REMAINING 

VALUES IN STORED 
DIFFERENCES 



.106 




OMIT VALUES 
FOUND IN HIGHER 
CERTIFICATES IN 
CHAIN 



FIG.4A 



12 



EP0827974A2 




Y ^ 



114 



DETERMINE AND 
SELECT NEXT 

HIGHEST 
CEmiFIGATE 



STORE RECORDS) 
DIFFERENCES IN SMART 
CARD 



I 



.116 



RECREATE EACH 
CERTIHCATEAND 
COMPARE TO ORIGINAL 



^118 




122 
^ 



DELETE DATA 
STORED ON SMART 
CARD 



Fia4B 



13 



EP0927974A2 



ROOTCA 

NAMB=SErROO 
ISSUER=SETROOrB' 
AUTHKEYID=SEr ROOT B 
TYPE=RCA 
BASIC CONSTRAIhfTB=CA 
SERIAL NUMBER=102 
SIGNATURB«Xe899 
PUBLIC KEY=0X4322 



ROOTCA 

NAMEsBRANDX 
I^DET^iSEIiaQQTB 
AUTHKEYID=SErRi 
TYP&BCA 
BASIC CONSTRAIMrS=CA 
SERIAL NUMBER=201 
SIGNATUR&0X1231 
PUBUCKEY«<0(34534 



62A 



64A 



ROOTCA 

NAME=SET ROOTS 
SSUEa=BRANDX 
AUTHKEYID=SET ROOT B 
TYPE=CCA 

BASIC CONSTRAINTS=CA| 
SERIAL NUMBER=501 
SIGNATURB=0X987345 
PUBUC KEY-0X434523 



V 

68A 



Fias 



14 



